added commit c546d73 to not clobber (or fail on) podman secrets if the mirror-registry install command is re-ran on an existing install.

Thanks Sol, we'll take a look at this week and follow up soon.

@dmage @jonathankingfc Anything you want to adjust before we stamp? Seems like a reasonable ask and passes existing tests.

FWIW I've tested a bunch of different scenarios on a vagrant & physical install, upgrade, re-install over existing install. All worked as expected.

makes sense to me, but just curious about limitations or drawbacks of implementing this.

do we also lose ability to recover initial passwords since they are generated in memory and no longer persisted to disk anywhere?

Good question, the passwords are generated and written to the ~/.containers path for the given user:

$ echo "bar" | podman secret create foo -
f46441aa419510b9f5303e52e
$ podman secret ls
ID                         NAME        DRIVER      CREATED        UPDATED
f46441aa419510b9f5303e52e  foo         file        7 seconds ago  7 seconds ago
$ podman secret inspect foo
[
    {
        "ID": "f46441aa419510b9f5303e52e",
        "CreatedAt": "2024-03-04T14:00:21.239208863Z",
        "UpdatedAt": "2024-03-04T14:00:21.239208863Z",
        "Spec": {
            "Name": "foo",
            "Driver": {
                "Name": "file",
                "Options": {
                    "path": "/home/<username>/.local/share/containers/storage/secrets/filedriver"
                }
            },
            "Labels": {}
        }
    }
]

$ cat /home/<username>/.local/share/containers/storage/secrets/filedriver/secretsdata.json
{
  "f46441aa419510b9f5303e52e": "YmFyCg=="

$ cat /home/<username>/.local/share/containers/storage/secrets/filedriver/secretsdata.json | jq -r '.[]' | base64 -d -
bar

I considered adding an update to the readme pointing this out, but thought maybe it would add more confusion than it was worth? I definitely don't mind adding a section discussing how to identify the passwords. They're not really ever needed for customers to use, since they're internal services that aren't exposed outside of the pod, but for troubleshooting purposes I could see wanting to know how to identify them.